IAM Identity Center + Microsoft Entra ID の構成で Amazon QuickSight の外部 ID フェデレーション機能をスタンダードエディションで使ってみた

いわさです。

先日、IAM Identity Center + Entra ID の環境で Amazon QuickSight の統合機能が使えるか確認しました。

文中でも紹介しているのですが、まず IAM Identity Center と QuickSight の統合機能は、新しく QuickSight をセットアップする時のみ有効化が可能です。
また、この統合機能は QuickSight の エンタープライズエディションでのみ利用が可能です。

では既に QuickSight を運用中で新しくサインアップするのが困難な場合、あるいはスタンダードエディションを使っている場合はどうしようも無いのでしょうか。

外部 ID フェデレーションの仕組みを使って QuickSight へシングルサインオンさせる

IAM Identity Center は SAML がサポートされている任意のアプリケーションの ID ソースとして使うことが出来ます。
そして AWS IAM は ID プロバイダーリソースを定義することで、SAML 認証した ID プロバイダーに対して IAM ロールを払い出すことが出来ます。
そして QuickSight は IAM でのユーザーアクセスが可能なので、この仕組みを使って IAM Identity Center からカスタム SAML アプリケーションとして QuickSight を統合することが出来ます。

この方法は QuickSight のスタンダードエディションでもサポートされているのと、既存の QuickSight 環境に対して適用することが可能です。

公式ドキュメントだとこのあたりになります。

ただし、上記は IAM Identity Center に関する記述がありません。
以前はあったのですが、現在は冒頭の記事で紹介したネイティブな統合機能が推奨されているからでしょうか。以下についてのドキュメントのみが確認出来ました。

構築手順

前提として、IAM Identity Center と関係の無い AWS アカウント上に QuickSight をスタンダードエディションでサインアップしておきます。
今回知ったのですがスタンダードエディションの場合だと QuickSight の管理メニューにシングルサインオン（SSO）のメニューが無いですね。本当にスタンダードエディションで使えるのか？まぁやってみますか。

ちなみに、IAM Identity Center と QuickSight を実行するアカウントの間には AWS 上の信頼はなくて、SAML としての関係性しかないので、同一組織じゃなくてもこの構成は取ることが出来るはずです。

IAM Identity Center で QuickSight カスタムアプリケーションを構成する

IAM Identity Center + QuickSight 統合機能は AWS マネージドアプリケーションとして IAM Identity Center では管理されますが、今回使いたい構成はカスタムアプリケーションとして構成するものとなります。

アプリケーションカタログに「Amazon QuickSight」が存在しているので選択します。

で、構成画面に「ステップバイステップの手順を表示」というボタンがありまして、選択すると公式ドキュメントは異なる構成手順の画面が表示されます。今回はその手順をベースに構築を行っています。

アプリケーションの構成画面で「IAM Identity Center SAML メタデータファイル」をダウンロードしておきます。これ後から別のところでアップロードします。

アプリケーションのプロパティ、アプリケーションメタデータはデフォルトの状態で OK です。
次のようになっているか確認しましょう。

アプリケーションが作成されました。

IAM ID プロバイダと IAM ロールを構成する

まだこの時点では QuickSight へのシングルサインオンは出来ません。
この IAM Ideneity Center のユーザーがこのSAML アプリケーションを利用した時に、IAM ロールを引き受けれるように構成します。

IAM のメニューから「ID プロバイダ」を選択し、新しいプロバイダを作成します。

プロバイダのタイプは「SAML」を、メタデータドキュメントとして先ほど IAM Identity Center のカスタムアプリケーション追加時にダウンロードしていたメタデータをアップロードしてください。

ID プロバイダはこれで OK です。
イメージとしては SAML 用の IAM ユーザーが作成されたようなものでしょうか。メタデータの内容に従って ID プロバイダーからのアクセスが許可される感じです。

この時点ではまだ権限が設定されていないので、IAM ロールを作成して ID プロバイダに関連付けをします。
ID プロバイダの画面からロールの割り当てを選択し、新しいロールを作成しましょう。

信頼されたエンティティタイプで SAML 2.0 フェデレーションを選択します（ID プロバイダから新しいロールを作成した場合は自動選択される）
SAML 2.0 ベースのプロバイダーに先ほど作成した ID プロバイダを選択し、許可されるアクセスは「プログラムと AWS マネジメントコンソールへのアクセスを許可する」を選択します。

ロールに割り当てるポリシーは事前に QuickSight でアクセスするユーザー権限に応じて設定をしておきます。
今回は次のようにquicksight:CreateReaderを許可するようにしてみました。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "quicksight:CreateReader",
            "Resource": "*"
        }
    ]
}

QuickSight と IAM ポリシーの関係については、だいぶ前に書いたやつですが次の記事も良ければ見てみてください。
このポリシーによって自己プロビジョニングされる QuickSight ユーザーのロールも決まります。

ポリシーをアタッチしてロールが作成されると、次のように ID プロバイダを信頼する IAM ロールが作成されていると思います。

IAM ロールの ARN と、ID プロバイダの ARN を控えておいてください。
次の設定で使います。

属性マッピングを編集

また IAM Identity Center に戻ります。
アカウント間を行ったり来たりちょっと面倒なんですが頑張りましょう。ここ設定して終わりです。

QuickSight 用に作成したカスタムアプリケーションを開き、「属性マッピングを編集」を選択します。

ここで SAML 認証の際に受け渡す属性を設定します。
デフォルトに加えて、次の赤枠の２つのユーザー属性を追加します。
属性名は以下です。

• https://aws.amazon.com/SAML/Attributes/Role
• https://aws.amazon.com/SAML/Attributes/PrincipalTag:Email

値ですが、Role については「ロールARN,IDプロバイダARN」の形式で入力します。
私が作成したリソースの場合だと次のような感じです。

arn:aws:iam::123456789012:role/hoge0313createreader,arn:aws:iam::123456789012:saml-provider/hoge0313quicksight

アプリケーションにユーザーを追加してアクセス

あとはカスタムアプリケーションに IAM Identity Center のユーザーを追加します。

IAM Identity Center のポータル側へアクセスしましょう。
Microsoft Entra ID でサインインします。

アプリケーション一覧に QuickSight が表示されていますね。
アクセスしてみましょう。

QuickSight へのアクセスが行われます。

その後、初めて QuickSight へアクセスするユーザーの場合はメールアドレスの入力を行います。
このメールアドレスは IAM Identity Center で属性マッピングしたメールアドレスと同様である必要があります。
プロビジョニング時に自動でメールアドレスを連携して入力不要でユーザー作成する機能もエンタープライズでは使うことが出来るのですが、後述します。

アクセスすることが出来ました。
こちら実は閲覧者ではなく管理者になってしまっていますが、こちらは割愛してますが検証中に IAM ポリシーのアクションを変更してしまっているためと思われます。

Not authorized to perform sts:AssumeRoleWithSAML

実は今回の検証過程で IAM Identity Center から QuickSight アプリケーションへアクセスした際に次のようなエラーが発生しました。

Not authorized to perform sts:AssumeRoleWithSAML (Service: AWSSecurityTokenV20111201; Status Code: 403; Error Code: AccessDenied; Request ID: 83c70b38-962f-410b-a53d-947b97327a0c; Proxy: null). Please try again.

トラブルシューティングとして次のガイドラインが提供されており、ひとつづつチェックしました。

SAML レスポンスで指定された IAM ロールなどのスペルが間違っていないかまず確認しました。
具体的には属性マッピングの際に指定した次の値です。
今回は間違っておりませんでしたが、大文字小文字なども区別されるのでまずはこちらを確認しましょう。

今回は別の観点である「SAML アサーションが PrincipalTag 属性を使用するように設定されている場合、信頼ポリシーにも sts:TagSession アクションを含める必要があります。」が対象でした。

PrincipalTag:Emailを指定していたのですが、ロールの信頼ポリシーにsts:TagSessionを含めておりませんでした。
そういえば以前このタグを連携する時にポリシーの記述を追加したことがありました。

今回は信頼ポリシーに次の記述を追加することで正常にアクセス出来るようになりました。ご参考までに。

さいごに

本日は IAM Identity Center + Microsoft Entra ID の構成で Amazon QuickSight の外部 ID フェデレーション機能をスタンダードエディションで使ってみました。

今回の方法であれば既存の QuickSight 環境へ適用出来ます。
ただし、IAM Identity Center 統合機能とは異なり、グループの同期機能をサポートしておらず、QuickSight 側でロールやユーザーの管理がある程度必要になります。
可能であれば IAM Identity Center + QuickSight の統合機能を使いたいところですね。